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1.  Introduction 


Taxonomies  exist  to  provide  a  shared  framework  and  lexicon  making  it  possible  for  one  to 
distinguish  between  Malus  domestica  and  Citrus  sinensis  because  without  a  clear  shared 
taxonomy  one  could  easily  find  oneself  comparing  apples  to  oranges.  I  used  the  binomial  name 
for  apples  and  orange  to  illustrate  several  key  points  in  one  of  the  best  known  taxonomies.  In 
1735  Carolus  Linnaeus  published  Systema  Naturae  creating  a  taxonomy  which  serves  as  the  basis 
of  the  classification  still  in  use  today. ^  This  system  is  hierarchical  with  kingdoms,  phyla,  classes, 
orders,  family,  genus,  and  species.  One  of  the  key  strengths  of  the  Linnaeus’  system  is  the  use  of 
trivial  names  or  binomial  names.  Thus,  we  may  refer  to  Malus  domestica  and  not  Platae 
Angiosperms  Eudicots  Rosids  Rosales  Rosaceae  Malus  domestica.  Although  the  path  from  the 
root  to  the  leaf  is  highly  valuable,  it  is  clearly  unworkable  in  most  applications. 

To  be  useful  a  taxonomy  must  be  unique,  complete,  and  relational.  Unique  implies  that  each  item 
should  have  one  and  only  one  place  within  the  taxonomy.  Complete  means  that  everything  should 
have  a  place  in  the  taxonomy  or  that  the  taxonomy  may  be  easily  expanded  to  create  a  place  for  it. 
Relational  means  that  similar  items  are  grouped  together  in  such  a  way  as  to  allow  us  to  make 
useful  generalizations.  In  this  way  there  is  a  place  for  everything,  everything  is  in  its  place,  and  its 
location  tells  us  something  useful  about  it. 

As  we  consider  the  use  of  a  taxonomy  for  the  vulnerabilities  of  Supervisory  Control  and  Data 
Acquisition  (SCADA)  systems,  there  are  issues  such  as  attacks,  controls  and  principles  that  we 
would  like  to  easily  link  to  vulnerabilities.  “A  ‘vulnerable  state’  is  ‘any  state  which  enables  a  user 
to  read  information  without  authorization,  modify  information  without  authorization,  or  grant  or 
deny  an  entity  access  to  a  resource  without  authorization.’  Attacks  exploit  one  or  more 
vulnerabilities;  however,  attacks  are  not  vulnerabilities  themselves.  Controls  are  the  systems  put 
in  place  to  ensure  that  confidentiality,  integrity,  availability,  and  authenticity  of  the  information.  A 
vulnerability  could  be  defined  as  the  absence  or  failure  of  a  control.  Thus,  we  see  that  there  is  a 
one-to-many  relationship  between  attacks  and  vulnerabilities,  but  there  may  be  a  one-to-one 
relationship  between  vulnerabilities  and  controls.  Principles  are  axiomatic  security  practices  that 
are  universally  accepted.  These  include  “least  privilege”,  which  means  that  actors  should  posses 
only  the  privileges  that  are  necessary  to  complete  the  task  and  “defense  in  depth”  which  means 
that  controls  should  not  have  a  single  point  of  failure.  Vulnerabilities  violate  one  or  more  of  these 
principles.  Vulnerabilities,  attacks,  controls,  and  principle  all  play  an  important  role  in 
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implementing  a  secure  system;  therefore,  we  would  like  the  taxonomy  to  be  able  to  assist  in 
relating  them. 

The  purpose  that  a  taxonomy  is  intended  to  serve  also  plays  a  significant  role  in  the  construction 
of  the  taxonomy.  The  primary  purpose  of  this  taxonomy  is  to  provide  a  framework  for  an 
assessment  of  the  countermeasures  currently  available  to  protect  SCADA  and  other  Industrial 
Control  Systems  (ICS).  A  secondary  purpose  is  to  provide  a  framework  for  security  assessments 
and  risk  scoring  of  SCADA  and  ICS.  This  is  a  highly  general  purpose  and  significantly  different 
from  the  highly  specialized  purpose  of  assessing  vulnerabilities  in  SCADA  network  protocols  that 
Igure  addressed.^ 


2.  Background 


In  1996  Bishop  and  Bailey  published  a  critical  analysis  of  vulnerability  taxonomies.  They  used 
the  race  conditions  in  xterm  and  mkdir  along  with  the  buffer  overflow  in  fingerd  to  illustrate  the 
problems  that  they  observed  with  uniqueness  in  the  Program  Analysis  study,  the  Research  into 
Secure  Operating  Systems  study  and  Aslam’s  Taxonomy."^ 

In  1995  Bishop  described  a  taxonomy  of  UNIX  vulnerabilities.  His  system  was  composed  of  6 
axes:  vulnerability  class,  time  of  introduction,  exploitation  domain,  effect  domain,  minimum 
number,  and  source.^  He  demonstrates  its  uniqueness  by  analyzing  and  classifying  1 1  different 
vulnerabilities.  The  system  is  not  complete  in  that  there  are  vulnerabilities  that  will  not  fit  into  it. 
For  example,  on  2013  April  16,  an  attack  was  conducted  against  the  Metcalf  substation  where 
telephone  cables  in  an  underground  vault  were  cut,  and  snipers  were  able  to  damage  several 
critical  pieces  of  equipment.  The  substation  was  down  for  almost  a  month  while  technicians 
repaired  the  damage.^  There  is  no  place  for  physical  vulnerabilities  in  Bishop’s  model.  He  defines 
6  axes  specifically  wanting  his  taxonomy  to  relate  to  intrusion  detection;  however,  he  only  uses 
the  vulnerability  class  axis  for  this  purpose.  The  other  axes  seem  to  be  somewhat  superfluous. 
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In  2008  Igure  et  al.  published  a  survey  of  attack  and  vulnerability  taxonomies  specifically  looking 
for  a  taxonomy  that  would  be  helpful  in  security  assessments.  They  found  none  but  identified 
features  useful  in  such  a  taxonomy.^ 

The  Common  Vulnerabilities  and  Exposures  lisC  provides  a  unique  id  for  every  known 
vulnerability;  however,  this  taxonomy  only  tells  us  the  year  that  a  vulnerability  was  discovered.  It 
provides  a  fine  key  into  the  database  but  does  not  help  classify  the  problem  in  any  meaningful 
way. 

In  201 1  Zhu  et  al.  published  a  taxonomy  of  cyber  attacks  on  SCADA  systems.  They  did  a  good 
job  illustrating  the  key  differences  between  SCADA  systems  and  typical  information  technology 
(IT)  systems;  however,  they  didn’t  actually  propose  a  taxonomy.^ 

Tsipenyuk  et  al.  created  a  taxonomy  designed  to  aid  developers  in  recognizing  common  coding 
errors,  which  they  named  the  “Seven  Pernicious  Kingdoms”.^  Each  “kingdom”  is  further 
subdivided  into  “phyla”. 

Igure  makes  a  very  important  observation, “Several  different  taxonomies  exist  because  each  is 
mostly  applicable  only  to  a  particular  field  of  interest."^  Going  back  to  our  Systema  Naturae 
analogy,  it  is  almost  as  if  the  efforts  in  taxonomy  so  far  have  looked  at  classifying  all  Equidae  and 
Canidae.  To  define  a  complete  taxonomy,  we  will  need  to  take  a  few  steps  back  to  get  the  big 
picture. 
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3.  Controls 


If  we  accept  that  a  vulnerability  is  either  the  absence  or  failure  of  a  control,  then  it  makes  sense 
for  us  to  look  at  control  taxonomies.  There  exist  several  control  taxonomies  used  in  the 
assessment  space.  The  National  Security  Agency  (NSA)  developed  the  Information  Security 
(INFOSEC)  Assessment  Methodology  (lAM)  to  encapsulate  the  lessons  that  they  had  learned 
over  years  of  doing  information  security  assessments.  The  National  Institute  of  Standards  and 
Technology  (NIST)  published  Special  Publication  800-53,  which  contains  a  taxonomy  of  security 
controls  used  to  support  certification  and  accreditation.^'  A  combination  of  1  or  2  or  more  of 
these  may  provide  a  framework  for  a  overarching  taxonomy  of  vulnerabilities. 

3.1  Sample  Vulnerabilities 

To  evaluate  the  various  existing  taxonomies  and  the  proposed  taxonomy,  we  will  consider  the 
following  vulnerabilities:  the  mkdir,  xterm  and  fingerd  vulnerability  examined  by  Matt  Bishop, 
along  with  the  cable  and  sniper  vulnerabilities  exposed  by  the  Metcalf  incident. 

mkdir  The  mkdir  flaw  was  identified  as  a  race  condition  where  an  operation  that  must  be  atomic 
is  not.  The  orginal  mkdir  command  first  used  mknode  to  create  the  directory  then  set  the 
permissions.  This  2-step  process  allowed  someone  to  swap  the  node  created  by  mknode 
with  another  file.  The  fix  was  to  create  the  system  call  mkdir,  which  atomically  does  the 
work."' 

xterm  The  xterm  flaw  was  identified  as  a  race  condition  where  determining  the  ability  to  access  a 
file  and  opening  the  file,  which  needs  to  be  atomic  to  be  secure,  was  done  in  2  steps,  and 
allows  an  external  process  to  swap  files  between  the  determination  and  the  open.  Xterm  ran 
setuid  root  to  allow  it  to  create  an  entry  in  utmp  and  to  set  the  permission  on  the  psuedo 
terminal.  Both  of  these  operations  happen  very  early  in  the  operation  of  xterm,  and 
honoring  least  privilege  would  have  xterm  relinquish  those  elevated  privileges  as  soon  as 
they  were  no  longer  necessary.  Modem  versions  of  xterm  are  no  longer  setuid  root  because 
they  have  isolated  the  privileged  operations  into  a  separate  executable  that  is  setuid  root."' 

fingerd  The  Morris  worm  exploited  a  buffer  overflow  in  the  fingerd  program  to  gain 

unauthorized  access  to  computer  systems  on  the  Internet.  Fingerd  expected  a  name  of  not 
more  than  512  characters;  however,  it  did  not  check  that  the  data  it  read  from  the  network 
contained  only  512  characters.  Supplying  more  than  512  characters  allowed  the  attacker  to 


4 


overflow  the  buffer  and  write  onto  the  stack.  The  access  to  the  stack  was  exploited  to 
implant  machine  code  that  gave  the  attacker  shell  access  and  set  the  return  address  of  the 
current  function  to  the  implanted  machine  code."^ 

cable  During  the  Metcalf  incident,  attackers  were  able  to  gain  entrance  to  an  underground  vault 
near  the  highway.  Once  they  had  gained  access  to  the  vault,  they  were  able  to  sever 
telephone  cables  in  a  way  that  would  be  difficult  to  repair.^  This  is  clearly  a  vulnerability  in 
the  physical  security  of  the  site  allowing  unauthorized  access  to  critical  infrastructure. 

sniper  During  the  Metcalf  incident,  snipers  were  able  to  damage  several  pieces  of  critical 

equipment  bringing  the  substation  offline  for  almost  a  month.  One  might  consider  this  a 
physical  security  vulnerability;  however,  requiring  that  organizations  maintain  control  of  an 
area  large  enough  to  prevent  or  harden  each  component  against  this  kind  of  attack  would  be 
prohibitively  expensive.  It  would  be  better  to  consider  this  as  a  recovery  vulnerability.  Some 
eventualities  cannot  be  prevented  and  contingency  plans  must  be  in  place  to  mitigate  them. 

3.2  NSA  lAM 

The  NSA  lAM  divides  controls  into  3  classes  and  18  categories  as  shown  in  Table  l.^°  These 
classes  and  categories  do  a  great  job  of  instructing  an  assessor  where  to  look  for  vulnerabilities 
and  encompass  many  of  the  vulnerabilities  that  were  unaddressed  in  other  taxonomies.  There  are 
still  holes;  in  fact,  none  of  the  vulnerabilities  that  Bishop  discussed  have  a  clear  place  in  this 
taxonomy  until  a  patch  or  new  revision  corrected  them  and  the  Technical/Maintenance  control 
should  have  corrected  them,  or  a  signature  was  developed  and  the  Techincal/Malicious  code 
protection  should  correct  this.  The  closest  is  Technical/System  Assurance,  but  that  really  speaks 
to  certification  and  accreditation.  The  cable  and  sniper  vulnerabilities  exploited  in  the  Metcalf 
incident  would  have  been  covered  in  “Operational/Physical  Enviroment”  and 
“Management/Contingency  Planning”,  respectively. 

3.3  DOD  Instruction  8500.2  Information  Assurance 

In  2003  the  Department  of  Defense  published  instruction  8500.2  Information  Assurance  (lA) 
Implementation.'^  This  instruction  contained  a  catalog  of  157  controls  as  seen  in  Table  2.  The 
controls  are  over  10  years  old  and  are  out-of-date;  however,  it  is  the  taxonomy  that  is  of  interest. 

They  divided  the  space  into  8  subject  areas.  Each  subject  area  had  a  name  and  a  2-letter 
abbreviation.  The  subject  area  contained  controls.  Each  control  had  a  name  and  a  2-letter 
abbreviation.  Controls  also  had  levels  which  were  expressed  as  the  numbers  1,  2,  or  3.  This  gave 
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Table  1  NSA  lAM  classes  and  categories 


Management 

Technical 

Operational 

•  INFOSEC 

•  Indentification  and  Authentication 

•  Media  Controls 

Documentation 

•  Account  Management 

•  Fabeling 

•  INFOSEC  Roles  and 

•  Session  Controls 

•  Physical  Environment 

Responsibilities 

•  Auditing 

•  Personnel  Security 

•  Contingency 

•  Malicious  Code  Protection 

•  Eduction  Training 

Planning 

•  Maintenance 

and  Awareness 

•  Configuration 

•  System  Assurance 

Management 

•  Networking/Connectivity 

•  Communication  Security 

Table  2  DODI  subject  areas 


Abbreviation 

Subject  Area  Name 

Controls 

DC 

Security  Design  &  Configuration 

31 

lA 

Identification  and  Authentication 

9 

EC 

Enclave  and  Computing  Environment 

48 

EB 

Enclave  Boundary  Defense 

8 

PE 

Physical  and  Environmental 

27 

PR 

Personnel 

7 

CO 

Continuity 

24 

VI 

Vulnerability  and  Incident  Management 

3 

each  control  an  abbreviation  where  the  first  2  letters  were  for  the  subject  area,  the  second  2  letters 
were  the  control,  and  the  number  designated  the  level.  For  example,  the  abbreviation  ECCT-2 
specificies  the  Enclave  and  Computing  Environment,  Encryption  for  Confidentiality  (Data  in 
Transit),  level  2.  Each  control  was  also  mapped  to  an  lA  service:  Integrity,  Confidentiality,  or 
Availability. 

The  vulnerabilities  like  the  ones  in  mkdir,  xterm,  and  fingerd  do  not  have  a  well  defined  home  in 
this  taxonomy.  The  closest  we  find  is  Security  Design  and  Configuration/Software  Quality; 
however,  that  serves  as  a  broad  category  for  everything  contained  in  that  taxonomy,  and 
specifically  called  for  validation  methods  to  be  in  place  to  prevent  them. 
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The  vulnerabilities  exposed  in  the  Metcalf  incident  are  covered  in  the  Physical  and  Environmental 
and  Continuity  subject  areas.  Several  confidentiality  controls  in  the  Physical  and  Environmental 
subject  area  are  designed  to  ensure  that  only  authorized  personnel  have  access  to  sensitive  areas 
and  would  have  addressed  the  cable  vulnerability.  The  continuity  controls  for  availability  seem  to 
center  around  the  use  of  an  alternate  site  to  address  the  sniper  vulnerability.  In  this  respect  the 
power  company  performed  well  because  power  was  rerouted  from  different  sites  to  avoid  a 
blackout.^ 

3.4  NIST  Special  Publication  800-53 

In  this  publication  NIST  defines  3  classes  and  18  families  as  shown  in  Table  3.  The  NS  A  lAM 
and  NIST  Security  Controls  share  the  same  classes,  and  many  of  their  categories  and  family  map 
one  to  one.  The  NIST  control  taxonomy  takes  it  one  step  further  down  by  enumerating  a  number 
of  controls  in  each  of  the  families.  The  NIST  taxonomy  also  has  the  advantage  of  containing  the 
baseline  controls  for  Certification  and  Accreditation  of  all  federal  government  systems. 


Table  3  NIST  classes  and  families 


Identifier 

Family 

Class 

Controls 

AC 

Access  Control 

Technical 

22 

AT 

Awareness  and  Training 

Operational 

5 

AU 

Audit  and  Accountability 

Technical 

14 

CA 

Security  Assessment  and  Authorization 

Management 

7 

CM 

Configuration  Management 

Operational 

9 

CP 

Contingency  Pfanning 

Operational 

10 

lA 

Identification  and  Authentication 

Technical 

8 

IR 

Incident  Response 

Operational 

8 

MA 

Maintenance 

Operational 

6 

MP 

Media  Protection 

Operational 

6 

PE 

Physical  Environment  Protection 

Operational 

19 

PL 

Pfanning 

Management 

6 

PS 

Personnef  Security 

Management 

8 

RA 

Risk  Assessment 

Management 

5 

SA 

System  and  Services  Acquistion 

Management 

14 

SC 

System  and  Communication 

Protection 

Technical 

34 

SI 

System  and  Information  Integrity 

Operational 

13 

PM 

Program  Management 

Management 

11 
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NIST  also  published  SP  800-82,  Guide  to  Industrial  Control  Systems  (ICS)  Security.  In  this 
publication  they  chose  to  provide  supplemental  guidance  for  several  of  the  SP  800-53  controls. 
Much  of  this  guidance  provides  compensatory  controls  for  those  controls  that  are  difficult  if  not 
impossible  to  implement  on  an  ICS.^^ 

Vulnerabilities  like  the  ones  in  mkdir,  xterm,  and  fingerd  do  not  have  a  clear  home  in  this 
taxonomy.  The  closest  place  would  Management/SA-8  Security  Engineering  Principles.  This 
control  simply  states  that  security  engineering  principles  are  applied  when  software  is  developed 
or  modified. 

Vulnerabilities  like  the  ones  exposed  in  the  Metcalf  incident  are  covered  in 
Operational/Contingency  Planning  and  Operational/Physical  Environment.  The  cable 
vulnerability  would  be  addressed  by  physical  environment  controls  that  require  a  formal 
protection  policy,  access  authorizations,  access  control,  etc.  The  sniper  vulnerability  would  by 
addressed  by  contingency  planning  controls  which  require  that  the  organization  have  a  plan,  that 
employees  are  trained  in  that  plan,  and  that  the  plan  include  recovery  and  reconstitution. 

3.5  Engineering  Principles 

The  NIST  Special  Publication  800-27  reviews  33  principles  into  6  categories  as  illustrated  in 
Table  4.1^ 


Table  4  NIST  principles 


Categories 

Principles 

Security  Foundations 

4 

Risk  Based 

7 

Ease  of  Use 

4 

Increase  Resilience 

8 

Reduce  Vulnerabilities 

6 

Design  with  Network  in  Mind 

4 

Considering  the  33  principles  outlined  in  SP  800-27,  we  will  review  some  of  the  vulnerabilites 
cited  by  Bishop  to  see  if  they  fit  uniquely.  The  mkdir  vulnerability  would  fit  into  Reduce 
Vulnerabilities/Principle  29  “Identify  and  prevent  common  errors  and  vulnerabilities”.^"^  One 
might  want  to  bin  the  xterm  vulnerability  in  Principle  29;  however,  it  is  most  properly  binned  in 
Reduce  Vulnerabilites/Principle  26  “Implement  least  privilege”. The  fingerd  vulnerability  could 
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be  binned  in  Risk  Based/Principle  6  “Assume  the  external  systems  are  insecure.” There  is  a  great 
deal  of  overlap  amongst  the  various  principles  and  clearly  this  taxonomy  would  fail  to  be  unique. 


Looking  at  the  vulnerabilies  exploited  in  the  Metcalf  incident,  we  find  the  cable  vulnerability 
could  be  addressed  by  Design  with  Network  in  Mind/Principle  30  “Implement  security  through  a 
combination  of  measures  distributed  physically  and  logically.”  However  promising  the  name 
may  look,  the  text  of  the  principle  would  not  lead  one  to  consider  securing  the  entrance  to  the 
underground  vault  that  contained  the  telephone  wires.  The  sniper  vulnerabilty  could  be  addressed 
by  Increase  Resilience/Priniciple  23  “Develop  and  exercise  contingency  or  disaster  recovery 
prodecures  to  ensure  appropriate  availability.”^"^  This  principle  does  require  plans  to  include  the 
various  phases  of  an  event  including  “a  return  to  normal  operation  phase.”'"^  This  taxonomy  only 
provides  a  place  for  half  of  the  vulnerabilities  we  selected  from  the  Metcalf  incident. 

3.6  Protection  Analysis  Study 

The  Protection  Analysis^  study  provides  the  following  information: 


1 .  Improper  protection  (initial  and  enforcement) 

la.  improper  choice  of  initial  protection  domain  -  “incorrect  initial  assignment  of 
security  or  integrity  level  at  system  initialization  or  generation;  a  security  critical 
function  manipulating  critical  data  directly  accessible  to  the  use”; 

lb.  improper  isolation  of  implementation  detail  -  allowing  users  to  bypass  operating 
system  controls  and  write  to  absolute  input/output  addresses;  direct  manipulation  of  a 
“hidden”  data  structure  such  as  a  directory  file  being  written  to  as  if  it  were  a  regular 
file;  drawing  inferences  from  paging  activity 

lc.  improper  change  -  the  “time-of-check  to  time-of-use”  flaw;  changing  a  parameter 
unexpectedly; 

ld.  improper  naming  -  allowing  two  different  objects  to  have  the  same  name, 
resulting  in  confusion  over  which  is  referenced. 

le.  improper  deallocation  or  deletion  -  leaving  old  data  in  memory  deallocated  by  one 
process  and  reallocated  to  another  process,  enabling  the  second  process  to  access  the 
information  used  by  the  first;  failing  to  end  a  session  properly 

2.  Improper  validation  -  not  checking  critical  conditions  and  parameters,  leading  to  a 
process  addressing  memory  not  in  its  memory  space  by  referencing  through  a 
out-of-bounds  pointer  value;  allowing  type  clashes;  overflows 

3.  Improper  synchronization; 

3a.  improper  indivisibility  -  interrupting  atomic  operations  (e.g.  locking);  cache 


9 


inconsistency 

3b.  improper  sequencing  -  allowing  actions  in  an  incorrect  order  (e.g.  reading  during 
writing) 

4.  Improper  choice  of  operand  or  operation  -  using  unfair  scheduling  algorithms  that 
block  certain  processes  or  users  from  running;  using  the  wrong  function  or  wrong 
arguments. 


Bishop  has  already  demonstrated  how  to  uniquely  apply  vulnerabilities  to  these  classes;^  however, 
there  is  no  place  in  this  taxonomy  for  the  vulnerabilities  exploited  in  the  Metcalf  incident. 

3.7  Seven  Pernicious  Kingdoms 

Tsipenyuk  et  al.  divided  the  development  vulnerability  space  into  7  plus  1  kingdoms  and  85  phyla 
as  shown  in  Table  5.  They  reviewed  previous  taxonomy  attempts  and  show  how  these  taxonomies 
map  to  theirs.  They  also  demonstrate  that  their  taxonomy  is  both  more  general  and  complete. 
Previous  efforts  focused  on  vulnerabilities  in  operating  systems;  whereas,  this  taxonomy  expands 
to  cover  application  coding  errors  including  web  application  coding  errors.  This  taxonomy  is 
designed  to  incorporated  into  a  static  code  analysis  tool.^ 


Table  5  Seven  pernieious  kingdoms 


Number 

Kingdom 

Phyla 

1 

Input  Validation  and  Representation 

26 

2 

API  Abuse 

11 

3 

Seeurity  Features 

9 

4 

Time  and  State 

7 

5 

Errors 

4 

6 

Code  Quality 

9 

7 

Eneapsulation 

10 

* 

Environment 

9 

If  we  examine  this  taxonomy  against  Bishop’s  vulnerabilities,  we  find  that  each  fits  nicely  into  a 
kingdom  and  phylum.  The  mkdir  vulnerability  would  be  classified  as  a  Time  and  State/File 
Access  Race  Condition.  The  xterm  vulnerability  would  be  classified  as  a  Security  Features/Least 
Privilege  Violation.  The  fingerd  vulnerability  would  be  classified  as  Input  Validation  and 
Representation/Buffer  Overflow.  There  is  no  place  in  this  taxonomy  for  the  vulnerabilities 
exploited  in  the  Metcalf  incident. 
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4.  Proposal 


The  brief  survey  demonstrates  that  the  vulnerability  taxonomies  seem  to  be  too  laser  foeused  and 
are  missing  almost  all  vulnerabilities  that  are  not  direetly  related  to  software  development,  and  the 
eontrols  vulnerabilities  are  very  broad  and  do  not  eontain  the  level  of  detail  required  to  eapture 
software  vulnerabilities  in  any  reasonable  manner.  The  obvious  solution  is  to  somehow  eombine 
one  of  the  eontrol  taxonomies  with  one  of  the  vulnerability  taxonomies.  Of  the  eontrol 
taxonomies,  the  NSA  lAM  is  too  general  and  the  DODI  8500.2  is  obsolete  leaving  only  the  NIST 
800-53,  whieh  is  the  most  foeused  and  most  relevant  of  the  eontrol  taxonomies.  Of  the 
vulnerability  taxonomies,  the  “Seven  Pemieious  Kingdoms”  seems  to  be  the  riehest  and  most 
detailed. 

Seleeting  the  2  taxonomies  to  merge  only  solves  half  of  the  problem.  It  is  still  necessary  to  find 
some  way  to  combine  them.  The  NIST  800-53  defined  3  kingdoms:  management,  operational, 
and  technical.  These  kingdoms  deal  primarily  with  the  operations  of  an  information  system  and 
only  briefly  reference  its  development.  What  is  necessary  is  another  kingdom  to  encompass  the 
development  of  the  system.  This  would  provide  4  kingdoms:  management,  operational,  technical, 
and  development.  The  7  kingdoms  would  then  become  phyla  under  the  development  kingdom 
each  containing  several  classes.  The  Seven  Pernicious  Kingdoms  contain  an  eighth  kingdom 
called  environment,  which  is  a  bin  for  all  of  those  vulnerabilities  that  are  in  the  configuration  of 
the  system  and  not  in  the  software  development.  Elements  from  the  eighth  kingdom  will  be 
assumed  into  one  of  the  other  kingdoms  where  they  are  already  addressed. 

In  this  taxonomy  the  3  classes  from  NIST  800-53 — management,  technical,  and  operational — will 
be  joined  by  a  fourth  class,  development,  to  become  the  4  kingdoms.  The  subject  areas  from  the 
NIST  800-53  plus  the  kingdoms  from  the  7  kingdoms  will  all  become  phyla.  The  controls  from 
NIST  800-53  and  the  phyla  from  the  7  kingdoms  will  become  classes.  At  some  point  orders, 
families,  genae,  and  species  may  need  to  be  defined;  however,  if  necessary  that  will  addressed  in 
future  work. 

This  taxonomy  may  seem  to  have  a  problem  with  uniqueness.  For  example,  the  mkdir  problem 
would  have  been  place  in  one  leaf  of  the  tree  before  a  patch  or  upgrade  was  available  and  in  a 
different  leaf  of  the  tree  a  reasonable  time  after  the  patch  or  upgrade  was  available.  These  are  too 
completely  different  vulnerabilities  when  one  considers  the  big  picture.  The  vulnerability  that 
exists  a  reasonable  amount  of  time  after  a  patch  or  upgrade  is  available  is  a  symptom  of  a  failure 
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of  the  system  that  deploys  these  patches  or  upgrades.  Failure  to  recognize  this  diverts  the  focus 
and  resources  from  correcting  the  root  causes  to  addressing  the  symptoms. 

An  outline  of  the  proposed  taxonomy  is  provided.  Exact  definitions  and  examples  of  the  classes 
exist  in  the  source  documents  and  are  not  included  here. 

1.  Management 

(a)  CA  Security  Assessment  and  Authorization 

i.  CA-1  Security  Assessment  and  Authorization  Policies  and  Procedures 

ii.  CA-2  Security  Assessments 

hi.  CA-3  Information  Systems  Connections 
iv.  CA-4  Security  Certification  (Withdrawn) 

V.  CA-5  Plan  of  Action  and  Milestones 

vi.  CA-6  Security  Authorization 

vii.  CA-7  Continuous  Monitoring 

(b)  PL  Planning 

i.  PL-1  Sercurity  Planning  Policy  and  Procedures 

ii.  PL-2  System  Security  Plan 

hi.  PL-3  System  Security  Plan  Update  (Withdrawn) 
iv.  PL-4  Rules  of  Behavior 
V.  PL-5  Privacy  Impact  Assessment 
vi.  PL-6  Security-Related  Activity  Planning 

(c)  PS  Personnel  Security 

i.  PS-1  Personnel  Security  Policy  and  Procedures 

ii.  PS-2  Position  Categorization 
hi.  PS-3  Personnel  Screening 
iv.  PS-4  Personnel  Termination 
V.  PS-5  Personnel  Transfer 

vi.  PS-6  Access  Agreements 

vii.  PS-7  Third-Pary  Personnel  Security 
vih.  PS -8  Personnel  Sanctions 

(d)  RA  Risk  Assessment 
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i.  RA-1  Risk  Assessment  Policy  and  Procedures 

ii.  RA-2  Security  Categorization 

iii.  RA-3  Risk  Assessment 

iv.  RA-4  Risk  Assessment  Update  (Withdrawn) 

V.  RA-5  Vulnerability  Scanning 

(e)  SA  System  and  Services  Acquisition 

i.  SA-1  System  and  Services  Acquisition  Policy  and  Procedures 

ii.  SA-2  Allocation  of  Resources 

iii.  SA-3  Life  Cycle  Support 

iv.  SA-4  Acquisitions 

V.  SA-5  Information  System  Documentation 

vi.  SA-6  Software  Usage  Restrictions 

vii.  SA-7  User-Installed  Software 

viii.  SA-8  Security  Engineering  Principles 

ix.  SA-9  External  Information  System  Services 
X.  SA-IO  Developer  Configuration  Management 

xi.  SA-11  Developer  Security  Testing 

xii.  SA-1 2  Supply  Chain  Protection 

xiii.  SA-1 3  Trustworthiness 

xiv.  SA-14  Critical  Information  System  Component 

(f)  PM  Program  Management 

i.  PM- 1  Information  Security  Program  Plan 

ii.  PM-2  Senior  Information  Security  Officer 

iii.  PM- 3  Information  Security  Resources 

iv.  PM-4  Plan  of  Action  and  Milestones  Process 
V.  PM-5  Information  System  Inventory 

vi.  PM- 6  Information  Security  Measures  of  Performance 

vii.  PM-7  Enterprise  Architecture 

viii.  PM-8  Critical  Infrastrure  Plan 

ix.  PM-9  Risk  Managment  Strategy 

X.  PM- 10  Security  Authorization  Process 
xi.  PM- 11  Mission/Business  Process  Definition 
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2.  Operational 


(a)  AT  Awareness  and  Training 

i.  AT-1  Security  Awareness  and  Training  Policy  and  Procedures 

ii.  AT-2  Security  Awareness 

iii.  AT-3  Security  Training 

iv.  AT-4  Security  Training  Records 

V.  AT-5  Contacts  with  Security  Groups  and  Associations 

(b)  CM  Configuration  Management 

i.  CM-1  Configuration  Management  Policy  and  Procedures 

ii.  CM-2  Baseline  Configuration 

iii.  CM-3  Configuration  Change  Control 

iv.  CM-4  Security  Impact  Analysis 

V.  CM-5  Access  Restrictions  for  Change 

vi.  CM-6  Configuration  Settings 

vii.  CM-7  Least  Functionality 

viii.  CM-8  Information  System  Component  Inventory 

ix.  CM-9  Configuration  Management  Plan 

(c)  CP  Contingency  Planning 

i.  CP-1  Contingency  Planning  Policy  and  Procedures 

ii.  CP-2  Contingency  Plan 

iii.  CP-3  Contingency  Training 

iv.  CP-4  Contingency  Plan  Testing  and  Exercise 
V.  CP-5  Contingency  Plan  Update  (Withdrawn) 

vi.  CP-6  Alternate  Storage  Site 

vii.  CP-7  Alternate  Processing  Site 

viii.  CP-8  Telecommunications  Services 

ix.  CP-9  Information  System  Backup 

X.  CP- 10  Information  System  Recovery  and  Reconstitution 

(d)  IR  Incident  Response 

i.  IR-1  Incident  Response  Policy  and  Procedures 

ii.  IR-2  Incident  Response  Training 
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iii.  IR-3  Incident  Response  Testing  and  Exercise 

iv.  IR-4  Incident  Handling 
V.  IR-5  Incident  Monitoring 

vi.  IR-6  Incident  Reporting 

vii.  IR-7  Incident  Response  Assistance 

viii.  IR-8  Incident  Response  Plan 

(e)  MA  Maintenance 

i.  MA-1  System  Maintenance  Policy  and  Procedures 

ii.  MA-2  Controlled  Maintenance 

iii.  MA-3  Maintenance  Tools 

iv.  MA-4  Non-Local  Maintenance 
V.  MA-5  Maintenance  Personnel 

vi.  MA-6  Timely  Maintenance 

(f)  MP  Media  Protection 

i.  MP-1  Media  Protection  Policy  and  Procedures 

ii.  MP-2  Media  Access 

iii.  MP-3  Media  Marking 

iv.  MP-4  Media  Storage 
V.  MP-5  Media  Transport 

vi.  MP-6  Media  Sanitization 

(g)  PE  Physical  Environment  Protection 

i.  PE-1  Physical  and  Environmental  Protection  Policy  and  Procedures 

ii.  PE-2  Physical  Access  Authorization 

iii.  PE-3  Physical  Access  Control 

iv.  PE-4  Access  Control  for  Transmission  Medium 
V.  PE-5  Access  Control  for  Output  Devices 

vi.  PE-6  Monitoring  Physical  Access 

vii.  PE-7  Visitor  Control 

viii.  PE- 8  Access  Records 

ix.  PE-9  Power  Equipment  and  Power  Cabling 
X.  PE- 10  Emergency  Shutoff 
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xi.  PE- 11  Emergency  Power 

xii.  PE- 12  Emergency  Eighting 

xiii.  PE- 13  Eire  Protection 

xiv.  PE- 14  Temperature  and  Humidity  Controls 
XV.  PE- 15  Water  Damage  Protection 

xvi.  PE- 16  Delivery  and  Removal 

xvii.  PE- 17  Alternate  Work  Site 

xviii.  PE- 18  Eocation  of  Information  System  Components 
xix.  PD- 19  Information  Eeakage 
(h)  SI  System  and  Information  Integrity 

i.  STl  System  and  Information  Integrity  Policy  and  Procedures 

ii.  ST2  Elaw  Remediation 

iii.  STS  Malicious  Code  Protection 

iv.  ST4  Information  System  Monitoring 

V.  SI-5  Security  Alerts,  Advisories,  and  Directives 

vi.  ST6  Security  Eunctionality  Verification 

vii.  ST7  Software  and  Information  Integrity 

viii.  SI-8  Spam  Protection 

ix.  ST9  Information  Input  Restrictions 
X.  ST  10  Information  Input  Validation 

xi.  STl  1  Error  Handling 

xii.  ST  12  Information  Ouput  Handling  and  Retention 

xiii.  ST  13  Predictable  Eailure  Prevention 

3.  Technical 

(a)  AC  Access  Control 

i.  AC-1  Acess  Control  Policy  and  Procedures 

ii.  AC-2  Account  Management 

iii.  AC-3  Access  Enforcement 

iv.  AC-4  Information  Elow  Enforcement 
V.  AC-5  Separation  of  Duties 

vi.  AC-6  Eeast  Privilege 
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vii.  AC-7  Unsuccessful  Login  Attempts 

viii.  AC-8  System  Use  Notification 

ix.  AC-9  Previous  Login  (Access)  Notification 
X.  AC- 10  Concurrent  Session  Control 

xi.  AC- 1 1  Session  Lock 

xii.  AC- 12  Session  Termination  (Withdrawn) 

xiii.  AC- 13  Supervision  and  Review — Access  Control  (Withdrawn) 

xiv.  AC- 14  Permitted  Actions  without  Identification  or  Authentication 
XV.  AC- 15  Automated  Marking  (Withdrawn) 

xvi.  AC- 16  Security  Attributes 

xvii.  AC- 17  Remote  Access 
xviii.  AC- 1 8  Wireless  Access 

xix.  AC- 19  Access  Control  for  Mobile  Devices 
XX.  AC-20  Use  of  External  Information  Systems 

xxi.  AC-21  User-Based  Collaboration  and  Information  Sharing 

xxii.  AC-22  Publicly  Accessible  Content 

(b)  AU  Audit  and  Accountability 

i.  AU-1  Audit  and  Accountability  Policy  and  Procedures 

ii.  AU-2  Auditable  Events 

iii.  AU-3  Content  of  Audit  Records 

iv.  AU-4  Audit  Storage  Capacity 

V.  AU-5  Response  to  Audit  Processing  Eailures 

vi.  AU-6  Audit  Review,  Analysis,  and  Reporting 

vii.  AU-7  Audit  Reduction  and  Report  Generation 

viii.  AU-8  Time  Stamps 

ix.  AU-9  Protection  of  Audit  Information 
X.  AU- 10  Non-repudiation 

xi.  AU-1 1  Audit  Record  Retention 

xii.  AU-1 2  Audit  Generation 

xiii.  AU-1 3  Monitoring  for  Information  Disclosure 

xiv.  AU- 14  Session  Audit 

(c)  lA  Identification  and  Authentication 
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i.  IA-1  Identification  and  Authentication  Policy  and  Procedures 

ii.  IA-2  Identification  and  Authentication  (Organizational  Users) 
hi.  IA-3  Device  Identification  and  Authentication 

iv.  IA-4  Identifier  Management 
V.  IA-5  Authenticator  Management 

vi.  IA-6  Authenticator  Feedback 

vii.  IA-7  Cryptographic  Module  Authentication 

viii.  IA-8  Identification  and  Authentication  (Non-Organizational  Users) 

(d)  SC  System  and  Communication  Protection 

i.  SC-1  System  and  Communications  Protection  Policy  and  Procedures 

ii.  SC-2  Application  Partitioning 
hi.  SC-3  Security  Function  Isolation 

iv.  SC-4  Information  in  Shared  Resources 
V.  SC-5  Denial  of  Service  Protection 

vi.  SC-6  Resource  Priority 

vii.  SC-7  Boundary  Protection 

viii.  SC-8  Transmission  Integrity 

ix.  SC-9  Transmission  Confidentiality 
X.  SC- 10  Network  Disconnect 
xi.  SC- 11  Trusted  Path 

xh.  SC- 12  Cryptographic  Key  Establishment  and  Management 
xih.  SC- 13  Use  of  Cryptography 
xiv.  SC- 14  Public  Access  Protections 
XV.  SC- 15  Collaborative  Computing  Devices 
xvi.  SC- 16  Transmission  of  Security  Attributes 
xvh.  SC- 17  Public  Key  Infrastructure  Certificates 
xvih.  SC- 18  Mobile  Code 
xix.  SC- 19  Voice  Over  Internet  Protocol 

XX.  SC-20  Secure  Name/Address  Resolution  Service  (Authoritative  Source) 
xxi.  SC-21  Secure  Name/Address  Resolution  Service  (Recursive  or  Caching  Resolver) 
xxh.  SC-22  Architecture  and  Provisioning  for  Name/ Address  Resolution  Service 
xxih.  SC-23  Session  Authenticity 
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xxiv.  SC-24  Fail  in  Known  State 
XXV.  SC-25  Thin  Nodes 
xxvi.  SC-26  Honeypots 

xxvii.  SC-27  Operating  System-Independent  Applications 
xxviii.  SC-28  Protection  of  Information  at  Rest 
xxix.  SC-29  Heterogeneity 
XXX.  SC-30  Virtualization  Techniques 
xxxi.  SC-31  Covert  Channel  Analysis 
xxxii.  SC-32  Information  System  Partitioning 
xxxiii.  SC-33  Transmission  Preparation  Integrity 
xxxiv.  SC-34  Non-Modifiable  Executable  Programs 

4.  Development 

(a)  Input  Validation  and  Representation 

i.  Buffer  Overflow 

ii.  Command  Injection 

iii.  Cross-Site  Scripting 

iv.  Format  String 

V.  HTTP  Response  Splitting 

vi.  Illegal  Pointer  Value 

vii.  Integer  Overflow 

viii.  Log  Forging 

ix.  Path  Manipulation 
X.  Process  Control 

xi.  Resource  Injection 

xii.  Setting  Manipulation 

xiii.  SQL  Injection 

xiv.  String  Termination  Error 

XV.  Struts:  Duplicate  Validation  Forms 

xvi.  Struts:  Erroneous  validate()  Method 

xvii.  Struts:  Form  Bean  Does  Not  Extend  Validation  Class 
xviii.  Struts:  Form  Field  Without  Validator 


19 


xix.  Struts:  Plug-in  Framework  Not  in  Use 
XX.  Struts:  Unused  Validation  Form 

xxi.  Struts:  Unvalidated  Aetion  Form 

xxii.  Struts:  Validator  Turned  Off 

xxiii.  Struts:  Validator  Without  From  Field 
xxiv.  Unsafe  JNI 
XXV.  Unsafe  Refleetion 
xxvi.  XML  Validation 
(b)  API  Abuse 

i.  Dangerous  Funetion 

ii.  Direetory  Restrietion 

iii.  Heap  Inspeetion 

iv.  J2EE  Bad  Praetiees:  getConneetion(). 

V.  J2EE  Bad  Praetiees:  Soekets. 

vi.  Often  Misused:  Authentieation 

vii.  Often  Misused:  Exeeption  Handling 

viii.  Often  Misused:  Eile  System 

ix.  Often  Misused:  Privilege  Management 
X.  Often  Misused:  Strings 
xi.  Uneheeked  Return  Value 
(e)  Seeurity  Eeatures 

i.  Inseeure  Randomness 

ii.  Eeast  Privilege  Violation 

iii.  Missing  Aeeess  Control 

iv.  Password  Management 

V.  Password  Management:  Empty  Password  in  Config  Pile 

vi.  Password  Management:  Hard-Coded  Password 

vii.  Password  Management:  Password  in  Config  Pile 

viii.  Password  Management:  Weak  Cryptography 

ix.  Privaey  Violation 

(d)  Time  and  State 
i.  Deadloek 
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ii.  Failure  to  Begin  a  New  Session  upon  Authentication 

iii.  File  Access  Race  Condition:  TOCTOU 

iv.  Insecure  Temporary  File 

V.  J2EE  Bad  Practice:  System.exit() 

vi.  J2EE  Bad  Practice:  Threads 

vii.  Signal  Handling  Race  Conditions 

(e)  Errors 

i.  Catch 

ii.  Empty  Catch  Block 

iii.  Overly-Broad  Catch  Block 

iv.  Overly-Broad  Throws  Declaration 

(f)  Code  Quality 

i.  Double  Eree 

ii.  Inconsistent  Implementations 

iii.  Memory  Eeak 

iv.  Null  Dereference 
V.  Obsolete 

vi.  Undefined  Behavior 

vii.  Uninitialized  Variable 

viii.  Unrelease  Resource 

ix.  Use  After  Eree 

(g)  Encapsulation 

i.  Comparing  Classes  by  Name 

ii.  Data  Eeaking  between  Users 

iii.  Eeftover  Debug  Code 

iv.  Mobile  Code:  Object  Hijack 

V.  Mobile  Code:  Use  of  Inner  Class 

vi.  Mobile  Code:  Non-Einal  Public  Eield 

vii.  Private  Array-Typed  Eield  Returned  from  a  Public  Method 

viii.  Public  Data  Assigned  to  Private  Array-Typed  Eield 

ix.  System  Information  Eeak 

X.  Trust  Boundary  Violation 
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5.  Conclusions  and  Future  Work 


Most  of  the  taxonomies  for  vulnerabilities  suffer  myopia  in  that  they  are  too  strietly  foeused  on 
one  area  of  eoneern  to  be  of  general  use.  Taxonomies  of  eontrols  are  broad  enough  to  be  of 
general  use;  however,  they  are  foeused  on  the  postdeployment  of  the  system  and  have  little 
support  for  the  development  of  the  systems.  In  many  eases  there  does  not  appear  to  be  a  eontrol 
for  a  vulnerability  until  after  there  is  a  fix;  either  an  upgrade  or  a  malieious  eode  signature. 
Adding  an  existing  very  speeifie  vulnerability  taxonomy  to  a  eontrol  taxonomy  may  provide  the 
breadth  and  depth  neeessary  in  a  general  taxonomy.  Although  the  genesis  of  this  work  was  to 
develop  a  taxonomy  for  SCADA  systems,  SCADA  systems  are  a  speeialized  form  of  IT,  and  the 
eommunity  would  be  better  served  by  adding  any  SCADA  speeifie  vulnerabilities  to  a  broader  IT 
taxonomy  than  to  develop  yet  another  myopie  taxonomy. 

The  next  step  is  to  take  this  taxonomy  and  analyze  eaeh  vulnerability  or  eontrol  for  existing 
eounter  measures  for  the  purpose  of  determining  the  residual  risk.  This  will  enable  us  to  diseover 
unaceeptable  gaps.  These  gaps  may  be  used  to  ereate  researeh  direetion. 
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